In general, to fix log injection you should ensure any user-controlled value is normalized before being logged: strip or replace newline and carriage-return characters (and often other non-printable control characters), and clearly separate user data from static log text. For text logs, removing line breaks is typically sufficient; for HTML logs, HTML-encode.

In this file, the best fix with minimal behavioral change is to (1) make the sanitization function clearly focused on removing CR/LF (and, optionally, other control chars) and (2) apply it to all logged header-derived values. The code already does (2); we only need to adjust (1) to a simpler, recommendation-aligned implementation that static analysis tools are more likely to recognize. Specifically, in server/server.js around lines 107–113, replace the current sanitize definition that uses a broad control-character regex with a simpler one that explicitly strips \r and \n (and, if desired, a small, explicit additional set like \t). Leave the subsequent console.log calls as-is since they already use sanitize(...).

Concretely:

• In server/server.js, update the sanitize helper inside the /api/webhooks/github handler to:
  • Coerce values to strings safely (handling null/undefined).
  • Replace \r and \n with spaces (or remove them).
• No other changes to routing, logging, or imports are necessary.

In general, the fix is to ensure that any user-controlled value written to logs is normalized so it cannot alter log structure (no CR/LF or other control chars) and is clearly delimited. That means replacing control characters with safe placeholders and optionally constraining to a conservative character set.

For this specific case, the best approach without changing functionality is to tighten the sanitize helper used at the logging point. We’ll (a) limit the header value to a reasonable length to avoid log flooding, and (b) more clearly strip all non-printable characters and normalize whitespace, then use that consistently in the log line. This keeps the logs human-readable, does not affect downstream logic (the raw id is still used later in webhooks.receive), and directly addresses CodeQL’s concern.

Concretely, in server/server.js inside the /api/webhooks/github handler:

• Replace the current sanitize implementation with one that:
  • Converts null/undefined to an empty string.
  • Casts to string.
  • Removes all characters outside a safe printable range.
  • Collapses internal whitespace (including tabs) to single spaces.
  • Truncates to a fixed maximum length (e.g., 200 characters) to prevent log abuse.
• Keep using sanitize(name), sanitize(id), and sanitize(contentType) in the console.log calls as before.

No new imports or external libraries are required; this can be done with plain string methods and regular expressions.

General fix: ensure any user-controlled value written to logs is sanitized with a clearly defined, robust function that removes/neutralizes control characters and visually delimits user input. Then consistently use that function when logging such values.

Best concrete fix here:

• Keep a single, named sanitizeForLog helper that:
  • Converts null/undefined to an empty string.
  • Converts the value to string.
  • Replaces all carriage returns, line feeds, and other control characters with a safe placeholder (space).
  • Optionally trims leading/trailing whitespace.
• Use sanitizeForLog for each header before logging: name, id, and contentType.
• Make user-controlled portions in log messages clearly delimited (e.g., wrapped in quotes).

Changes needed in server/server.js:

• Replace the inline sanitize arrow function at line 108 with a named sanitizeForLog that is clearly oriented to log safety.
• Update the console.log calls for Event, Delivery ID, and Content-Type to use sanitizeForLog and clearly mark the value (e.g., "Content-Type: '%s'").
• No new imports are needed; all logic is implemented inline.

This keeps existing functionality (logging the same semantics) but hardens the sanitization and makes it clearer to both humans and tools that log injection has been intentionally addressed.

General approach: ensure that any user‑controlled data included in log messages is both validated and sanitized before logging. For IDs expected to be numeric, we can validate and coerce them to a safe representation; for arbitrary strings, we should strip control characters (including newlines) with a central sanitizeLog helper, and consistently apply it to any error messages or values that may originate from user input.

Best concrete fix here:

1. Validate and normalize installationId once at the top of syncGitHubData:

   • Parse it with parseInt.
   • If parsing fails (NaN), throw an error before any logging.
   • Use this parsed integer (installationIdInt) everywhere (for logging and GitHub client calls).
   • When logging, we then log a non‑tainted integer, which removes the need to treat it as user input in that log entry.

2. Sanitize error messages before logging in syncGitHubData’s catch block:

   • Wrap error.message with sanitizeLog when logging and when persisting into SyncHistory.results.
   • This ensures control characters in error messages (which sometimes embed raw input, such as IDs or user strings) cannot manipulate log structure.

3. Keep the existing sanitizeLog helper as is and reuse it; we don’t introduce new dependencies or change public behavior of the API, only input validation/log formatting.

Concrete changes in server/src/services/syncService.js:

• In syncGitHubData:
  • Introduce const installationIdInt = parseInt(installationId, 10); and validate it.
  • Update the log on line 55 to use installationIdInt (a safe integer, not user string).
  • Use installationIdInt instead of repeating parseInt(installationId, 10) for GitHub client initialization and installation lookup.
• In the catch block (lines ~529–540):
  • Sanitize error.message when logging: console.error('Error in syncGitHubData:', sanitizeLog(error.message));
  • When building results.errors[0].error, use sanitizeLog(error.message) instead of the raw message.

No changes are required in server/src/routes/api.js for this issue.